Sumo Logic エージェント型ログ送信のアーキテクチャを考える – 集中管理型

Sumo Logic ではエージェント型のログ送信方法を、Installed Collector と呼びます。

Sumo Logic にログを送信する方法として、クラウド環境であろうとオンプレミス環境であろうと、OS に管理者権限でアクセスできる場合は、このInstalled Collector (https://help.sumologic.com/docs/send-data/installed-collectors/）を使うことができます。
さらにエージェント型のログ送信においても、既存のログ管理やネットワークポリシーによっては、何かしらの方法で一度一箇所にログを集めてから、分析基盤／プラットフォームにログを送信するパターンが考えられます。

Sumo Logic のアーキテクチャだと、以下の図のように、ログ収集対象のサーバーのそれぞれにコレクターをインストール「ローカルデータコレクション」する場合と、ログ集中管理サーバーに集めてからコレクターによってログを送信「セントラライズドデータコレクション」するイメージです。

今回は、集中管理型のログ収集についてアーキテクチャと設定方法を確認していきます。

まず

「ローカルデータコレクション」と「セントラライズドデータコレクション」（集中管理型のログ収集）の使い分けについて簡単にまとめます。

ローカルデータコレクションの使い所

• 対象ホストが多い場合（ログ送信の負荷を分散し、ログ集中管理サーバーの運用を減らす）
• 自動デプロイが可能な場合
• Sumo Logic コレクターのトラブルシューティングがしやすい

セントラライズドデータコレクション（集中管理型のログ収集）の使い所

• 既存のログシステムが利用可能な場合
• アウトバウンドに通信制御がある場合
• 対象ホストへのエージェントインストールが難しい場合（ホストリソースへの考慮や、極度にミッションクリティカルなホスト）

このブログでは、セントラライズドデータコレクション（集中管理型のログ収集）を採用しようと思った時の整理として確認いただければと思います。

集中管理型のログ収集で想定されるアーキテクチャ

システムが存在しているプラットフォーム内に、単一の OS で構成されていることもあれば、複数の異なる OS が存在していたり、サーバーとネットワーク機器が混在するなど、さまざまあるかと思います。
いくつかのケース別に分けて、確認していきたいと思います。

Windows OS が統一された環境／ Windows OS のみ集中管理型のログ収集を行う

１． WEF (Windows Event Forwarding) と WEC (Windows Event Collector) を使ってログを集中管理サーバーに集め、Installed Collector で Sumo Logic に送信する

Windows サーバーが WEF クライアントとして、Windows Centralized Data Collector で WEC サービスを稼働してイベントログを受け取ります。
受け取ったイベントログは 集中管理サーバー の Windows Event Log システムに保存され、そのデータがさらに Sumo Logic の Installed Collector で Sumo Logic に送信されます。
Windows イベントログはバイナリデータで扱われますが、その形式のまま集中管理サーバーに送られるため余計な手間やオーバーヘッドが生じません。

WEF クライアントとしての設定は、Windows DC によるグループポリシーで設定するか、端末毎のローカルグループポリシーによって設定します。 下記はMSのローカルグループポリシーでの設定方法に関するドキュメントです。

WEC サービスは集中管理サーバー側で Windows Event Log のサブスクリプションの作成が必要です。
下記はMSの WEC 設定に関するドキュメントです。

WEF クライアント側からのプッシュ型か、WEC サービスからのプル型かを選ぶことができます。この通信には Windows リモート管理サービスが使われ、TCP 5985 または TCP 5986 ポートを使います。プッシュ型は集中管理サーバーのインバウンド通信になりますが、プル型だと WEF クライアントへのインバウンド通信の開放が必要になるので、プッシュ型の方が管理がしやすいと思います。
下記はMSの利用ポートに関するドキュメントです。

また、集中管理サーバーには Sumo Logic の Installed Collector をインストールして、ソースの設定「Windows Event Log Source」を行います。
設定手順は下記のドキュメントを参照して行います。

２． リモートプロシージャコール（RPC）を使ってログを集中管理サーバーに集め、Installed Collector で Sumo Logic に送信する

集中管理サーバーにインストールした Sumo Logic の Installed Collector からリモートプロシージャコールを使ってリモートサーバーのイベントログを収集し、そのまま Sumo Logic に転送します。
この場合も、イベントログは集中管理サーバーまでバイナリデータで扱われ、Installed Collector で JSON 形式などに変換され Sumo Logic に送信されていそうです。（先程の WEC を使ったデータ送信も Installed Collector からの処理は同じと思われます。）

このアーキテクチャでは集中管理サーバーからリモートサーバーにアクセスする形になるので、リモートサーバー側でリモートプロシージャコールに関連するポートを開放する必要があります。
必要なポートは、TCP 135,445,49152-65535 になります。

また、リモートサーバーでは、集中管理サーバーからイベントログにアクセスするために Event Log Reader グループにドメインユーザーを追加してあげる必要があります。

ポートの開放と Event Log Reader グループへのドメインユーザー追加方法については、下記のドキュメントを参照できます。

Windows サービスのポート要件参考：

RPC の動的ポートは範囲が大きいことと、セキュリティ上影響が大きいため、ポートの範囲を小さくしたり、アクセスできる対象をIPアドレスや Windows ファイアウォールドメインを限定する対応がとられることがあり、こちらでもその方法が紹介されています。

また、集中管理サーバーには Sumo Logic の Installed Collector をインストールして、ソースの設定「Windows Event Log Source」を行います。
ソースは先程と同じですが、設定内容が異なります。
設定手順は下記のドキュメントを参照して行います。

Syslog がネイティブでサポートされている Unix系 OS で統一された環境／ Unix系 OS のみ集中管理型のログ収集を行う

１． Syslog サーバを構築して、そのサーバーを集中管理サーバーとし、Installed Collector で Sumo Logic に送信する

Installed Collector をインストールする集中管理サーバーに、Syslog デーモン等を動作させ通常の Syslog サーバーとして稼働させます。
Syslog で受け取ったログデータは集中管理サーバーのローカルストレージのファイルに書き込まれ、Installed Collector がローカルファイルを検索して差分のログデータを Sumo Logic に送信します。
送信されるデータは Syslog フォーマットになります。

集中管理サーバーには Sumo Logic の Installed Collector をインストールして、ソースの設定「Local File Source」を行います。
設定手順は下記のドキュメントを参照して行います。
https://help.sumologic.com/docs/send-data/installed-collectors/sources/local-file-source/

他にも（これは Unix系 の OS に限った話ではないですが）、Syslog の替わりに Fluentd や Logstash に置き換えて考えていただくことも可能です。

２． Installed Collector が Syslog クライアントからのログを受信し、そのログを Sumo Logic に送信する

集中管理サーバーにインストールした Sumo Logic の Installed Collector が Syslog サーバーの替わりにログを受信することができます。
受け取ったログはそのまま Sumo Logic に転送することができます。
送信されるデータは Syslog フォーマットになります。

リモートサーバー側で Syslog クライアントとしての設定を行います。
送信先は集中管理サーバーのIP、ポートは Sumo Logic の Syslog ソースで設定するポートに合わせます。

集中管理サーバーには Sumo Logic の Installed Collector をインストールして、ソースの設定「Syslog Source」を行います。
設定手順は下記のドキュメントを参照して行います。

Windows OS と Syslog がネイティブでサポートされている Unix系 OS が混在していて単一の集中管理サーバーにしたい場合

これまでのアーキテクチャを見てきた通り Windows イベントログを扱う場合、Syslog サーバーでは Syslog フォーマットの変換が必要になり余計な手間や考慮点が増えます。
また、ネットワーク機器などではリモートへログ送信する手段が Syslog しかサポートされていない場合も多く、どうしても Syslog サーバーが必要になるケースがあります。
これまでのケースを組み合わせることで、単一の集中管理サーバーで両方のログフォーマットを扱うことができます。

Windows OS のアーキテクチャのどちらか（ WEF による送信または RPC による送信）と、Unix系 OS のアーキテクチャの２つ目の「Syslog Source」を使うことで Windows サーバー１台で集中管理サーバーを構築することができます。（図は WEF ですが、RPC でもいいです。）

まとめ

既存のログ管理システムを活用したい場合や、ネットワークセグメント毎のセキュリティポリシーがあって集中的にログを一度集める必要がある場合もあろうかと思います。
そんな時のログ送信アーキテクチャを検討する際に整理する材料として、本ブログをご活用いただければと思います。